System and apparatus for transaction fraud processing

ABSTRACT

A system for processing transaction data is provided. The system includes a fraud policy system that provides merchant fraud policy data. An order information data system receives order information data and the merchant fraud policy data and generates order information fraud score data, such as by modifying the order information data using the merchant fraud policy data and then scoring the modified order information data. A transaction authorization system receives the order information fraud score data and the merchant fraud policy data and generates client authorization data.

RELATED APPLICATIONS

This application is related to copending U.S. application Ser. No.10/196,586, entitled “SYSTEM AND APPARATUS FOR TRANSACTION DATA FORMATAND FUNCTION VERIFICATION,” filed Jul. 15, 2002, which is herebyincorporated by reference for all purposes.

FIELD OF THE INVENTION

The present invention pertains to the field of transaction dataprocessing. More specifically, the invention relates to a system andapparatus for transaction fraud processing that allows different fraudrules for each of a plurality of merchants to be modified from a centrallocation.

BACKGROUND

Transaction fraud processing systems are known in the art. Suchtransaction fraud processing systems receive transaction data frommerchants and generate a fraud score. The merchant then uses the fraudscore to determine whether to accept the transaction, decline thetransaction, or to request additional data.

While such transaction fraud processing systems perform certain usefulfunctions, the merchant must ensure that the data that has been enteredis in the proper format and falls within allowable boundaries for eachfinancial processing system. Each fraud processing system hasspecialized data formats and functions, which further complicates theprocessing of transaction fraud data. Furthermore, the merchant mustdetermine whether the transaction fraud data requires action, and mustremain up to date with any additional capabilities or modifications tothe transaction fraud processor's capabilities and data formats.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and apparatus forprocessing transaction data are provided that overcome known problemswith processing transaction data.

In particular, a system and apparatus for processing transaction dataare provided that facilitate processing of transaction fraud data toallow merchants to receive a simplified score, enhance the scoringfunctionality and to allow modifications to fraud scoring to be readilyaccommodated by merchants.

In accordance with an exemplary embodiment of the present invention, asystem for processing transaction data is provided. The system includesa fraud policy system that provides merchant specific fraud policy dataand functionality. An order information data system receives orderinformation data and the merchant fraud policy data and generates orderinformation fraud score data, such as by modifying the order informationdata using the merchant fraud policy data and then scoring the modifiedorder information data. A transaction authorization system receives theorder information fraud score data and the merchant fraud policy dataand generates client authorization data.

The present invention provides many important technical advantages. Oneimportant technical advantage of the present invention is a system andapparatus for processing transaction data that allows external orinternal fraud processing rules to be changed without requiring merchantinternal fraud processing rules to be changed. The present inventionalso allows merchants to set policies and for changes to be made tofraud processing rules for each merchant based on such policies withouthaving to upgrade fraud processing systems operated by each merchant.

Those skilled in the art will further appreciate the advantages andsuperior features of the invention together with other important aspectsthereof on reading the detailed description that follows in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system for transaction fraud processing inaccordance with an exemplary embodiment of the present invention;

FIG. 2 is a diagram of a system for providing transaction data format,fraud data format, and rules processing capability in accordance with anexemplary embodiment of the present invention;

FIG. 3 is a diagram of a system for merchant customization oftransaction fraud processing in accordance with an exemplary embodimentof the present invention;

FIG. 4 is a flow chart of a method for performing transaction fraudscreening in accordance with an exemplary embodiment of the presentinvention; and

FIG. 5 is a flow chart of a method for performing merchant fraud policymanagement in accordance with an exemplary embodiment of the presentinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the description which follows, like parts are marked throughout thespecification and drawings with the same reference numerals,respectively. The drawing figures may not be to scale and certaincomponents can be shown in generalized or schematic form and identifiedby commercial designations in the interest of clarity and conciseness.

FIG. 1 is a diagram. of a system 100 for transaction fraud processing inaccordance with an exemplary embodiment of the present invention. System100 allows transaction data to be processed to determine compliance withdata formats and rules of fraud scoring systems, transaction processingsystems, and other suitable systems, and provides transaction fraud datato merchants in a merchant-usable format.

System 100 includes payment processing system 102, transaction system104, merchant customization system 106, merchant system 108, transactionprocessing system 110, fraud policy system 112, credit card system 114,and external fraud scoring system 116, each of which can be implementedin hardware, software, or a suitable combination of hardware andsoftware, and which can be one or more software systems operating on ageneral purpose processing or server platform. As used herein, ahardware system can include discrete semiconductor devices, anapplication-specific integrated circuit, a field programmable gate arrayor other suitable devices. A software system can include one or moreobjects, agents, threads, lines of code, subroutines, separate softwareapplications, user-readable (source) code, machine-readable (object)code, two or more lines of code in two or more corresponding softwareapplications, databases, or other suitable software architectures. Inone exemplary embodiment, a software system can include one or morelines of code in a general purpose software application, such as anoperating system, and one or more lines of code in a specific purposesoftware application.

The systems of system 100 are coupled over communications medium 118. Asused herein, the term “couple” and its cognate terms, such as “couples”and “coupled,” can include a physical connection (such as a copperconductor), a virtual connection (such as through randomly assignedmemory locations of a data memory device), a logical connection (such asthrough logical gates of a semiconducting device), other suitableconnections, or a suitable combination of such connections. In oneexemplary embodiment, systems and components are coupled to othersystems and components through intervening systems and components, suchas through an operating system. Communications medium 118 can be a localarea network, a wide area network, a public network such as theInternet, the public switched telephone network, a wireless network, afiber optic network, other suitable media, or a suitable combination ofsuch media.

Payment processing system 102 receives merchant fraud policy data frommerchant system 108. In one exemplary embodiment, the merchant fraudpolicy data can include selections of one or more rules from availablerule sets, customized rules, or other suitable rules based on the typesof data that the merchant acquires from its customers or other suitabledata. Payment processing system 102 can provide rules that are providedfrom an external fraud scoring system 116, or other suitable rules, andstores the merchant-specific rules in merchant customization system 106.Fraud policy system 112 of merchant system 108 can be used by themerchant to select and implement the rules, to provide fraud policy dataand functionality to payment processing system 102, or to otherwiseestablish suitable rules.

After fraud processing or policy rules have been established, merchantsystem 108 sends transaction data to payment processing system 102through transaction processing system 110, which can be a web server orother suitable transaction processing systems. Transaction system 104 ofpayment processing system 102 processes the transaction in accordancewith one or more predetermined transaction processing rules. In thismanner, transaction system 104 performs rules and format verification inaccordance with the system and methods described in U.S. patentapplication Ser. No. 10/196,586 entitled “SYSTEM AND APPARATUS FORTRANSACTION DATA FORMAT AND FUNCTION VERIFICATION,” filed Jul. 15, 2002,which is hereby incorporated by reference for all purposes. Paymentprocessing system 102 uses transaction system 104 and merchantcustomization system 106 to ensure that transaction data complies withcredit card system 114 rules, external fraud scoring system 116 rules,and other suitable rules. Payment processing system 102 notifiesmerchant system 108 of any irregularities or nonconformities with suchtransaction data, thus allowing the transaction data to be correctedprior to submission to credit card system 114 and external fraud scoringsystem 116, or other suitable systems.

If all data format requirements have been met and transaction data rulesand fraud policy rules have been complied with, payment processingsystem 102 can perform an initial fraud determination, such as todetermine whether the transaction is a card-not-present transaction orother suitable processes. If the initial fraud determination indicatesthat the transaction should receive additional fraud processing, such aswhere the merchant requests such processing, the transaction data can betransmitted to external fraud scoring system 116. Payment processingsystem 102 can process the transaction data using the merchant policydata, such as to submit transaction data for external fraud scoring, toweight certain types of data fields to have greater significance thanothers, to request fraud scoring of selected data fields, to ignorecertain data fields, to use data fields that are available to thatmerchant, or to perform other suitable processes. Likewise, internalfraud scoring can be exclusively used, external fraud scoring system 116can be exclusively used, or other suitable processes or combinations ofprocesses can be performed.

Payment processing system 102 receives fraud scoring data, such as fromexternal fraud scoring system 116, from internal fraud scoringprocesses, or in other suitable manners. Such fraud scoring can includemultiple indicators, such that additional analysis can be required.Payment processing system 102 can retrieve the merchant fraud policydata from merchant customization system 106 and can perform additionalrules implementation on the fraud scoring data. In one exemplaryembodiment, an external fraud scoring system 116 may generate a fraudscore between 1 and 999, where merchant customization system 106 is usedto set ranges for scores that indicate a negative result, a positiveresult, and results requiring additional investigation. External fraudscoring system 116 can also generate one or more codes, where codes thatindicate an authorized transaction, and unauthorized transaction, and atransaction that requires additional verification can be selected basedon the merchant policy data.

Payment processing system 102 can then provide the fraud scoring dataand transaction data to merchant system 108 for transaction processingbased on the results from external fraud scoring system 116 and themerchant customization system 106. In one exemplary embodiment, thetransaction data provided to external fraud scoring system 116 isdifferent from the transaction data provided to credit card system 114.The transaction data, fraud scoring data, or other suitable data canthen be provided to merchant system 108.

In operation, system 100 allows transaction data to be processed todetect fraudulent transactions. System 100 allows fraud scoring frominternal or external processes to be used, and simplifies the merchantinterface with a fraud scoring system by allowing new fraud scoring datato be introduced for use in the fraud scoring system without requiringthe merchant to modify payment processing systems to accommodate the newfraud scoring data. System 100 also allows fraud rules, transactionrules, data formats, or other suitable data and decision logic to beimplemented for different merchants, credit card systems 114, externalfraud scoring systems 116, or other suitable systems or processes, suchthat data format and rule verification processing is provided. In thisexemplary embodiment, transaction data received from merchant systems108 is verified both for data field correctness and for compliance withrules, where the actual data values are checked to verify that they arewithin allowable ranges, types, sets, classes, or are otherwiseallowable or will not result in error messages from credit card system114, external fraud scoring system 116, or other systems.

FIG. 2 is a diagram of a system 200 for providing transaction dataformat, fraud data format, and rules processing capability in accordancewith an exemplary embodiment of the present invention. System 200includes transaction system 104 and order information data system 202,personal information data system 204, email address data system 206, IPaddress data system 208, bill later data system 210, stored value datasystem 212, and credit card data system 214 each of which can beimplemented in hardware, software, or a suitable combination of hardwareand software, and which can be one or more software systems operating ona general purpose processing platform.

Order information data system 202 provides order information data in apredetermined format, where data types allowable for the format arebased on data types required by credit card systems 114, external fraudscoring systems 116, or other suitable systems or functions. In oneexemplary embodiment, order information data system 202 can verify thatthe data is in the proper format, and can then perform additional dataprocessing on the data fields to identify any problems with data beforetransmission of the data to an external processing organization.Furthermore, order information data system 202 can implement necessaryfixes to such data, such as to correct obvious errors, make correctionsbased on the context of the data record, or to implement other suitableprocesses.

In one exemplary embodiment, order information data system 202 caninclude one or more of the following format fields and functions:

Length Field Name Comments 2 format E.g. order information format 3product delivery E.g. cash & carry, digital type content/text or images,digital goods, digital and physical, physical delivery required,renewals and recharges, shareware, and service 2 shipping carrier E.g.DHL, Federal Express, Greyhound, Purolator, USPS, or United ParcelService 1 shipping method E.g. lowest cost, carrier designated bycustomer, international, military, next day/overnight, store pickup, ortwo day service 6 Order Date E.g. date of order 6 Order Time E.g. timeof order

Personal information data system 204 provides personal information datain a predetermined format, where data types allowable for the format arebased on data types required by credit card systems 114, external fraudscoring systems 116, or other suitable systems or functions. In oneexemplary embodiment, personal information data system 204 can verifythat the data is in the proper format, and can then perform additionaldata processing on the data fields to identify any problems with databefore transmission of the data to an external processing organization.Furthermore, personal information data system 204 can implementnecessary fixes to such data, such as to correct obvious errors, makecorrections based on the context of the data record, or to implementother suitable processes.

In one exemplary embodiment, personal information data system 209 caninclude one or more of the following format fields and functions:

Length Field Name Comments 2 format indicator E.g. personal informationformat 8 date of birth E.g. date of birth 9 social security E.g. socialsecurity number number 3 currency type E.g. currency type of grosshousehold annual income 10 gross income E.g. gross household income 1residence status E.g. rent, own 2 years at E.g. number of years atcurrent residence residence 2 years at E.g. number of years worked withemployer current employer 1 checking account E.g. checking accountindicator 1 savings account E.g. savings account indicator

E-mail address data system 206 provides e-mail data in a predeterminedformat, where data types allowable for the format are based on datatypes required by credit card systems 114, external fraud scoringsystems 116, or other suitable systems or functions. In one exemplaryembodiment, e-mail data system 206 can verify that the data is in theproper format, and can then perform additional data processing on thedata fields to identify any problems with data before transmission ofthe data to an external processing organization. Furthermore, e-maildata system 206 can implement necessary fixes to such data, such as tocorrect obvious errors, make corrections based on the context of thedata record, or to implement other suitable processes.

In one exemplary embodiment, e-mail data system 206 can include one ormore of the following format fields and functions:

Length Field Name Definition 2 format indicator E.g. e-mail addressinformation 1 address type E.g. buyer address, giftee address N e-mailaddress E.g. e-mail address

IP address data system 208 provides IP address data in a predeterminedformat, where data types allowable for the format are based on datatypes required by credit card systems 114, external fraud scoringsystems 116, or other suitable systems or functions. In one exemplaryembodiment, IP address data system 208 can verify that the data is inthe proper format, and can then perform additional data processing onthe data fields to identify any problems with data before transmissionof the data to an external processing organization. Furthermore, IPaddress data system 208 can implement necessary fixes to such data, suchas to correct obvious errors, make corrections based on the context ofthe data record, or to implement other suitable processes.

In one exemplary embodiment, IP address data system 208 can include oneor more of the following format fields and functions:

Length Field Name Definition 2 format indicator E.g. IP addressinformation 1 address Subtype E.g. bill to address, buyer address Ncustomer IP E.g. customer's IP address address

Bill later data system 210 provides bill me later program data in apredetermined format, where data types allowable for the format arebased on data types required by credit card systems 114, external fraudscoring systems 116, or other suitable systems or functions. In oneexemplary embodiment, bill later data system 210 can verify that thedata is in the proper format, and can then perform additional dataprocessing on the data fields to identify any problems with data beforetransmission of the data to an external processing organization.Furthermore, bill later data system 210 can implement necessary fixes tosuch data, such as to correct obvious errors, make corrections based onthe context of the data record, or to implement other suitableprocesses.

In one exemplary embodiment, bill later data system 210 can include oneor more of the following format fields and functions:

Length Field Name Comments 2 format indicator E.g. bill later format 8shipping cost E.g. total shipping cost 5 T&C version E.g. terms &conditions version 8 customer E.g. date customer registered withregistration merchant date 2 customer type E.g. new, existing flag 4item category product description code assigned by bill later program 16pre-approval E.g. whether consumer has been pre- invitation approvednumber 4 merchant E.g. merchant promotional code promotional code 1customer E.g. customer changed password password change 1 customerbilling E.g. customer changed billing address change address 1 customere-mail E.g. customer e-mail change change 1 customer phone E.g. customerchanged phone number change

Stored value data system 212 provides stored value data in apredetermined format, where data types allowable for the format arebased on data types required by credit card systems 114, external fraudscoring systems 116, or other suitable systems or functions. In oneexemplary embodiment, stored value data system 212 can verify that thedata is in the proper format, and can then perform additional dataprocessing on the data fields to identify any problems with data beforetransmission of the data to an external processing organization.Furthermore, stored value data system 212 can implement necessary fixesto such data, such as to correct obvious errors, make corrections basedon the context of the data record, or to implement other suitableprocesses.

In one exemplary embodiment, stored value data system 212 can includeone or more of the following format fields and functions:

Length Field Name Comments 2 format indicator E.g. stored value format 1telephone type E.g. day, home, night, work 14 telephone number E.g. areacode, exchange. number, extension 30 name text E.g. name of personreceiving gift 30 address E.g. street address 28 address E.g. streetaddress 2 country code E.g. United States, Canada, Mexico 20 city E.g.city 2 state E.g. state 10 zip code E.g. zip code

Credit card data system 214 provides credit card data in a predeterminedformat, where data types allowable for the format are based on datatypes required by credit card systems 114, external fraud scoringsystems 116, or other suitable systems or functions. In one exemplaryembodiment, credit card data system 214 can verify that the data is inthe proper format, and can then perform additional data processing onthe data fields to identify any problems with data before transmissionof the data to an external processing organization. Furthermore, creditcard data system 214 can implement necessary fixes to such data, such asto correct obvious errors, make corrections based on the context of thedata record, or to implement other suitable processes.

In one exemplary embodiment, credit card data system 214 can include oneor more of the following format fields and functions:

Length Field Name Comments 16 merchant order E.g. identifier assigned tonumber customer order 2 method of E.g. the form of payment providedpayment by the customer 19 account number E.g. the payment accountidentifier 4 expiration date E.g. date the account may expire 6 merchantnumber E.g. identifier of merchant 12 amount E.g. transaction value 3currency code E.g currency of the transaction 1 transaction type E.g.indicator of the source of the transaction - retail store, catalog,Internet, et al

In operation, system 200 allows data formats and rules for externaltransaction data processing systems, transaction fraud scoring systems,or other suitable systems to be implemented. In one exemplaryembodiment, system 200 determines whether the proper format and theproper data values for such external systems have been implemented.System 200 then interfaces with the external systems, and translates asnecessary between such external systems and merchant systems andinternal systems.

FIG. 3 is a diagram of a system 300 for merchant customization oftransaction fraud processing in accordance with an exemplary embodimentof the present invention. System 300 includes merchant customizationsystem 106 and fraud policy interface system 302, merchant fraud datasystem 304, merchant notification system 306, and fraud scoring updatesystem 308, each of which can be implemented in hardware, software, or asuitable combination of hardware and software, and which can be one ormore software systems operating on a general purpose processingplatform.

Fraud policy interface system 302 receives fraud policy data from amerchant. In one exemplary embodiment, fraud policy interface system 302can allow a merchant to operate a fraud policy system 112 and to providethe fraud data on demand or in other suitable manners. Likewise, fraudpolicy interface system 302 can be operator-driven, where a localoperator of system 300 interfaces with a merchant representative viatelephone, e-mail or other suitable communications media, reviewsmerchant fraud policy data previously provided, or otherwise obtainsfraud policy data.

Merchant fraud data system 304 stores merchant fraud policy data anddecision logic functionality for use in processing transactions. In oneexemplary embodiment, merchant fraud data system 304 allows eachmerchant to customize transaction processing rules to accommodate dataobtained by the merchant, such as order information data, personalinformation data, e-mail address data, IP address data, bill later data,stored value data, credit card data or other suitable data. Merchantfraud data system 304 can further allow fraud scoring data received froman internal or external fraud scoring system to be processed so as toreduce the fraud scoring data to acceptable, data classes. In oneexemplary embodiment, the fraud scoring data can include an initialscore from 1 to 999, and merchant fraud data system 304 can identifyranges for scores to classify the fraud scoring data into classes suchas “low risk transaction,” “high risk transaction,” “medium risktransaction.”

Merchant notification system 306 notifies merchant system 108 of changesto fraud scoring data formats. In one exemplary embodiment, additionalfraud scoring functionality can be provided, such as based on orderinformation data, personal information data, email address data, IPaddress data, bill later data, stored value data, credit card data orother suitable data. Merchant notification system 306 can request amerchant to indicate whether any such additional data could be of use inprocessing transactions to identify fraudulent transactions, can notifya merchant of such changes when previous instructions from a merchanthave authorized modification to merchant rules for processingtransactions, and can perform other suitable functions.

Fraud scoring update system 308 receives fraud scoring update data, suchas from external fraud scoring system 116 or other suitable systems, andallows changes to be made to one or more merchant fraud rules ordecision logic. In one exemplary embodiment, fraud scoring update system308 can allow data formats to he changed, new data fields to be used,and can further allow mass changes to merchant fraud data rules so as toeliminate the need for individual changes of rules.

In operation, system 300 allows fraud policy and fraud scoring to beimplemented for a plurality of merchants in a centralized location.System 300 allows customized merchant rules to be set up and implementedfor transactions processed through a central transaction processingsystem, such that transactions can be screened for fraud based on eachmerchant's preferences on an ongoing basis. System 300 thus allows apayment processor to process transaction data and obtain fraud datawithout the need to treat individual merchants separately, classifymerchants who obtain fraud processing for processing through a separatesystem than merchants who don't receive fraud processing, orimplementing other technologically cumbersome processes.

FIG. 4 is a flow chart of a method 400 for performing transaction fraudscreening in accordance with an exemplary embodiment of the presentinvention. Method 400 begins at 402 where transaction data, such ascredit card data, and a fraud score request are received. In oneexemplary embodiment, a payment processing system can receive a largenumber of transactions, such as credit card transactions, stored valuetransactions, debit card transactions, electronic funds transfertransactions, or other suitable transactions, where such transactionseither may or may not indicate that fraud processing should beperformed. The method then proceeds to 404.

At 404 stored value fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may indicatethat fraud score processing should be performed that includes storedvalue data and other suitable data. Merchant customization data andrules can also be applied to the stored value fraud scoring. Likewise,if it is determined that stored value fraud scoring is not required, themethod proceeds to 406.

At 406 bill later fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may include afraud scoring indicator that indicates that bill later fraud scoring isto be performed using bill later data and other suitable data. Merchantcustomization data and rules can also be applied to the bill later fraudscoring. If no bill later fraud scoring is to be performed the methodproceeds to 408.

At 408 order information fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may include afraud scoring indicator that indicates that order information fraudscoring is to be performed using order information data and othersuitable data. Merchant customization data and rules can also be appliedto the order information fraud scoring. If no order information fraudscoring is to be performed the method proceeds to 410.

At 410 personal information fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may include afraud scoring indicator that indicates that personal information fraudscoring is to he performed using personal data and other suitable data.Merchant customization data and rules can also be applied to thepersonal information fraud scoring. If no personal information fraudscoring is to be performed the method proceeds to 412.

At 412 e-mail information fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may include afraud scoring indicator that indicates that e-mail fraud scoring is tobe performed using e-mail data and other suitable data. Merchantcustomization data and rules can also be applied to the e-mailinformation fraud scoring. If no e-mail information fraud scoring is tobe performed the method proceeds to 414.

At 414 IP address fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or fraud score data may include afraud scoring indicator that indicates that IP address fraud scoring isto be performed using IP address data and other suitable data. Merchantcustomization data and rules can also be applied to the IP address fraudscoring. If no IP address fraud scoring is to be performed the methodproceeds to 416.

At 416 credit card data fraud scoring is performed. In one exemplaryembodiment, the transaction data and/or credit card data may include afraud scoring indicator that indicates that credit card data fraudscoring is to be performed using credit card data and other suitabledata. Merchant customization data and rules can also be applied to thecredit card data fraud scoring. If no credit card data fraud scoring isto be performed the method proceeds to 418. Alternatively, fraud scoringat 404 through 416 can be combined into a single fraud scoringtransaction using a suitable combination of data, including individualdata fields from one or more format sets where suitable.

At 418, a third party score is obtained. In one exemplary embodiment, athird party fraud processor can be used to obtain fraud scores. In thisexemplary embodiment, the data to be provided to the third party fraudprocessor can first checked to ensure that it is in a proper format, andcan then be checked to ensure that proper data fields have beenprovided, so as to implement both format and rules processing. The datacan then be provided to the third party, and appropriate fraudprocessing data from the third party can be obtained. In one exemplaryembodiment, the response can include a score from 1 to 999,predetermined codes, or other suitable scores. The method then proceedsto 420. Likewise, internal fraud scoring can be implemented.

At 420 it is determined whether fraud is indicated. If no fraud isindicated the method proceeds to 422 and transaction processingproceeds. Otherwise, the method proceeds to 424 where merchant scoringdata is retrieved. In one exemplary embodiment, merchant scoring datacan include predetermined transaction score ranges for each merchant,predetermined transaction score codes for each merchant, or othersuitable data that is used to determine whether fraud has been indicatedon a merchant by merchant basis. The method then proceeds to 426.

At 426 a score is generated, such as “accept transaction,” “denytransaction,” “obtain further information,” or other suitable scores.Likewise, associated identifiers for such scores can also be used. Themethod then proceeds to 428.

At 428 it is determined whether fraud has been indicated, such as at amerchant system. In one exemplary embodiment, the scores generated at426 can be used to generate merchant notification data. If it isdetermined at 428 that fraud has not been indicated the method proceedsto 432 and the transaction continues. Otherwise, the method proceeds to430 where a recommended action is transmitted. In one exemplaryembodiment, the recommended action can be to deny the transaction, toobtain additional data, or to perform other suitable processes.

In operation, method 400 allows transactions to be processed to obtainfraud score data using data formats and rules. Method 400 further allowsfraud scoring data to be reduced to predetermined classes, so as toallow merchants to receive fraud processing instructions in accordancewith specific rules for that merchant, to avoid the need to reconfiguremerchant processing rules when fraud scoring data is modified orsupplemented, and to provide other suitable advantages.

FIG. 5 is a flow chart of a method 500 for performing merchant fraudpolicy management in accordance with an exemplary embodiment of thepresent invention. Method 500 begins at 502 where fraud scoringmodification data is received. In one exemplary embodiment, the fraudscoring modification data can include data received from a third partytransaction or fraud processor or other suitable sources that indicatethat a change to merchant fraud scoring rules may be required. Themethod then proceeds to 504. At 504 merchant fraud scoring data isdisplayed. For example, if it is determined that the fraud scoringmodification data cannot be handled without operator review or input,then the merchant fraud scoring data can be displayed. Otherwise themethod can proceed directly to 506.

At 506 it is determined whether a change in the merchant fraud scoringdata is required. In one exemplary embodiment, a change can be requiredif additional data fields have been provided that may be of interest toa merchant, if existing data fields have been changed to add subsets orotherwise alter the data fields in a manner that requires action, or ifother changes have been made. If it is determined at 506 that change isnot required the method proceeds to 508 where the merchant is notified.In one exemplary embodiment, the merchant can be notified of thedecision not to implement a change, so as to provide the merchant anopportunity to request that a change be made or that other suitableactions be implemented. The method can then return to 506, such as wherea merchant transmits data requesting that a change be performed.

If it is determined at 506 that a change is required, the methodproceeds to 510 where it is determined whether notification is required.In one exemplary embodiment, notification can be required if the changeis made to one or more predetermined data fields. If notification isrequired, the method proceeds to 508. Otherwise the method proceeds to512.

At 512 the changes to the merchant fraud scoring data are implemented.In one exemplary embodiment, the changes can be implementedautomatically, can be entered on a merchant-by-merchant basis, can beentered for all merchants in a class, or other suitable processes can beused. The method then proceeds to 514.

At 514 the changes implemented to the merchant fraud scoring data aredisplayed to an operator. In one exemplary embodiment, the changes canbe displayed in a manner that requests that the operator verify whetherany additional changes are required. If it is determined at 516 thatadditional changes are required the method returns to 502. Otherwise themethod proceeds to 518 where the modified client fraud scoring data isstored for subsequent use.

In operation, method 500 allows merchant fraud scoring to be processedthrough a centralized transaction processor, such as to allow aplurality of merchants to either request fraud scoring data, not requestfraud scoring data, and to request fraud scoring data having differentrules. Method 500 thus allows modifications to the merchant fraudscoring data to be made based on changes in external fraud scoringsystems, internal fraud scoring systems, individual merchant policies,or in other suitable manners.

Although preferred and exemplary embodiments of a system and apparatusof the present invention have been described in detail herein, thoseskilled in the art will also recognize that various substitutions andmodifications can be made to the systems and methods without departingfrom the scope and spirit of the appended claims.

1-20. (canceled)
 21. A method for processing transaction datacomprising: electronically receiving order information fraud processingdata from a plurality of merchants at a fraud scoring system;electronically transmitting transaction data from a merchant to thefraud scoring system using electronic data transmitting equipment; andgenerating fraud score data at the fraud scoring system by processingthe transaction data with the order information fraud processing ruledata.
 22. The method of claim 21 wherein receiving order informationfraud processing data further comprises receiving fraudulent transactiondata from each of the plurality of merchants.
 23. The method of claim 21wherein receiving order information fraud processing data furthercomprises receiving transaction-level email address data from each ofthe plurality of merchants.
 24. The method of claim 21 wherein receivingorder information fraud processing data further comprises receivingtransaction-level IP address data from each of the plurality ofmerchants.
 25. The method of claim 21 wherein receiving orderinformation fraud processing data further comprise receivingtransaction-level billing data from each of the plurality of merchants.25. The method of claim 21 wherein receiving order information fraudprocessing data further comprises receiving transaction-level storedvalue card data from each of the plurality of merchants.
 26. The methodof claim 21 further comprising: receiving fraud scoring update data; andgenerating notification data for transmission to one or more of theplurality of merchants.
 27. The method of claim 21 further comprising:receiving fraud scoring update data; and modifying fraud processing ruledata for one or more of the plurality of merchants.
 28. A method forprocessing transaction data comprising: receiving transaction fraud datafor a plurality of merchants; electronically extracting orderinformation data from the transaction fraud data and generating fraudscoring data therefrom; receiving authorization request data associatedwith a transaction that is being authorized; and generating transactionauthorization data using electronic data processing equipment thatincludes an authorization response and order-specific fraud score datausing the fraud scoring data.
 29. The method of claim 28 furthercomprising: extracting personal data from the transaction fraud data andgenerating the fraud scoring data therefrom; and generating thetransaction authorization data based on the extracted personal data. 30.The method of claim 28 further comprising: extracting email address datafrom the transaction fraud data and generating the fraud score datatherefrom; and generating the transaction authorization data based onthe extracted email address data.
 31. The method of claim 28 furthercomprising: extracting IP address data from the transaction fraud dataand generating the fraud score data therefrom; and generating thetransaction authorization data based on the ex acted IP address data.32. The method of claim 28 further comprising: extracting stored valuecard data from the transaction fraud data and generating the fraud scoredata therefrom; and generating the transaction authorization data basedon the extracted stored value card data.
 33. The method of claim 28further comprising: extracting billing data and from the transactionfraud data and generating the fraud score data therefrom; and generatingthe transaction authorization data based on the extracted billing data.34. The method of claim 28 further comprising receiving fraud scoringupdate data and generating merchant notification data.
 35. The method ofclaim 28 further comprising: receiving fraud scoring update data andgenerating merchant fraud policy change data for a merchant; andreceiving the merchant fraud policy change data and modifying merchantfraud data.
 36. A method for processing transaction data comprising:electronically receiving order information fraud data and associatedpersonal information for each of a plurality of transactions from eachof a plurality of merchants; electronically receiving transaction datafrom one of the merchants; processing the transaction data using theorder information fraud data and the associated personal data using afraud scoring system operating on electronic data processing equipmentto generate fraud score data and authorization data; and transmittingthe fraud score data and the authorization data in a single message. 37.The method of claim 36 wherein electronically receiving orderinformation fraud data further comprises receiving associated emailaddress data, wherein the transaction data is processed using the emailaddress data to generate the fraud score data.
 38. The method of claim36 wherein electronically receiving order information fraud data furthercomprises receiving associated IP address data, wherein the transactiondata is processed using the IP address data to generate the fraud scoredata.
 39. The method of claim 36 wherein electronically receiving orderinformation fraud data further comprises receiving associated storedvalue card data, wherein the transaction data is processed using thestored value card data to generate the fraud score data.
 40. The methodof claim 36 wherein electronically receiving order information frauddata further comprises receiving associated billing data, wherein thetransaction data is processed using the billing data to generate thefraud score data.